Finally, try_seek should provide deterministic seeking (same results after seeking)

should it? I've never seen seek as reproducing something rather navigating in an underlying stream. I would say the seek implementation for noise like this should do nothing. But if we do go on with seek in noise -> error then we should provide a wrapper that "eats" the seek operation. Basically:

struct DisableSeek;

impl Source for DisableSeek {
    ....
    
    fn try_seek() -> Result<() , _> {
        Ok(())
    }
}

Finally, try_seek should provide deterministic seeking (same results after seeking)

should it? I've never seen seek as reproducing something rather navigating in an underlying stream. I would say the seek implementation for noise like this should do nothing. But if we do go on with seek in noise -> error then we should provide a wrapper that "eats" the seek operation.

Here is an example of what would happen if we would "eat" seeks:

// Create with a fixed seed for determinism
let mut noise = pink::new_with_seed(44100, 12345);
// Play for a while, changing internal state
for _ in 0..1000 { noise.next(); }
// Rewind to the beginning
noise.try_seek(Duration::from_secs(0)).unwrap();

// Create another generator with the same seed
let mut noise2 = pink::new_with_seed(44100, 12345);
// Noises should be the same, but are not
assert_eq!(noise.next(), noise2.next());

...where you've got me however is that this is also true for my proposed implementation of WhiteNoise. We can get around that by storing/resetting original seeds, but I'm not sure about the added value vs. added complexity.

Thinking out loud: maybe we should remove _with_seed altogether and prevent illusions of determinism.

Thinking out loud: maybe we should remove _with_seed altogether and prevent illusions of determinism.

I think a deterministic noise gen is pretty neat but I struggle to think of a use case for it. Noise pretty much sounds the same regardless of seed right?

If we can not find a good use case now I would propose we scrap determinism. We can always add deterministic_noise later that goes through all kinds of complex slow tricks to stay perfectly deterministic.

If we can not find a good use case now I would propose we scrap determinism. We can always add deterministic_noise later that goes through all kinds of complex slow tricks to stay perfectly deterministic.

Yes, let's scrap it.

Thanks for all the hard work, it looks really nice.

Only thing I'm still unsure about is the seeking behavior. You've explained you want seeking to be reproducible/deterministic. I think we currently use seeking mostly for decoders. Effects just forward the seek or adjust it in the case of speed. Seeking in decoders is not 100% accurate but we find that okay. Isn't it strange to then disable seeking as soon as a piece of audio gets mixed with noise?

Isn't it strange to then disable seeking as soon as a piece of audio gets mixed with noise?

[emphasis mine]

Are you referring to Mix specifically? Because Mix::try_seek currently is always non-seekable regardless of its underlying sources.

But yes, you're probably right to not be too academic about this. It's probably OK to "eat" the seek and always return Ok(()) as any generator will continue to produce continuous noise as long as we don't reset the state.

Are you referring to Mix specifically? Because Mix::try_seek currently is always non-seekable regardless of its underlying sources.

your right! In my head that was already fixed. Well we should be able to fix that now that we have TrackPosition.

OK, a952f97 should do it, making all noise generators seekable. Once you agree, I can squash merge.

I think this epic is now done :)

Lets get it merged! I'll see if I can finish up get 0.21 ready for release tomorrow.